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REMARKS 

Claims 12-23 and 26-34 are pending in the Application, all of which stand 
rejected by the Office Action mailed May 04, 2009. Claims 12, 16, 26, and 27 are 
amended by this response. Claims 12 and 16 are independent claims, while claims 13- 
15 and 26-31, and 17-23 and 32-34, depend either directly or indirectly from 
independent claims 12 and 16, respectively. 

Applicants' representative Kevin Borg appreciated the opportunity to speak with 
Examiner Faris Almatrahi by telephone on April 21, 2009. Mr. Borg pointed out in 
general aspects of Applicants' claims not disclosed by the cited art. No agreement was 
reached with respect to any claim. 

Objections to the Drawings 

The drawings stand objected to under 37 CFR 1 .83(a), because "[t]he drawings 
must show every feature of the invention specified in the claims." (See Office Action at 
p. 2.) Specifically, the Office Action lists "saving the generated updating information in a 
storage, populating the updating information in an update store that acts as a repository 
of update packages whose lifecycle may be managed, enabling and disabling 
distribution of the updating information according to a state in the lifecycle, and 
packaging the saved updating information before communicating it to the distribution 
environment" as not shown in the drawings. (See id.) As an initial matter, Applicants 
respectfully submit that the original drawings are sufficient to satisfy 37 CFR 1.83(a). 
For example, Fig. 2 illustrates, inter alia, an Update Store (211) and a Life-cycle 
Management System for Update Packages (207) as part of a Carrier Network. (See 
Fig. 2.) Further, Fig. 3 also illustrates an Update Store and a Database. (See Fig. 3.) 
Applicants respectfully submit that these aspects of Figs. 2 and 3 would satisfy 37 CFR 
1.83(a) regarding, for example, "an update store that acts as a repository of update 
packages whose lifecycle may be managed." As another example, regarding "enabling 
and disabling distribution of the updating information according to a state in the 
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lifecycle," Applicants note that Fig. 20 illustrates an exemplary method of changing an 
update package state. 

In any event, Fig. 38 is added by this response, along with related amendments 
to the specification. Applicants respectfully submit no new matter is added, as Fig. 38 is 
based on disclosure previously provided at, for example, [0061] of the Specification. 
Additional support for Fig. 38 and, for instance, the asserted "enabling and disabling 
distribution of the updating information according to a state in the lifecycle" can be found 
at, for example, [0053] ("...Lifecycle management of update packages may also 
comprise changing status information such as, for example, information specifying who 
gets an update package, or when to start dispensing an update package..."). Thus, for 
example, this aspect of the presently claimed subject matter could be found in the 
drawings at, for example, Fig. 38, block 3860 "Manage Lifecycle of Update Packages." 

Applicants respectfully submit that at least the above-identified aspects of 
previous figures, as well as the various blocks illustrated in Fig. 38, satisfy the 
requirements of 37 CFR 1 .83(a). 

The Office Action also objects to Figs. 3-37 as being "obscured and features are 
difficult to make out." (See Office Action at p. 2.) Applicants respectfully traverse these 
assertions. Applicants also note that the present application has already gone through 
a number of Office Actions, with none of the previous Office Actions asserting that any 
figures were "obscured" or "difficult to make out." Nonetheless, Applicants submit 
herewith replacement drawing sheets for Figs. 1-37 that enlarge certain aspects of 
these figures to make them even easier to make out. Applicants respectfully submit that 
no new matter is added by these replacement drawing sheets. 

Applicants respectfully submit that the objections to the drawings are overcome 
as explained above, and request withdrawal of the objections to the drawings. 
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Rejection of Claims Under 35 U.S.C. §103 

Claims 12-23 and 26-34 stand rejected under 35 U.S.C. §103 as being 
unpatentable over Thurston et a/., U.S. Publication No. 2003/0217193 (hereinafter 
"Thurston") in view of Hind et a/., U.S. Patent No. 7,069,452 (hereinafter "Hind"). 
Applicants respectfully traverse the rejection of those claims as discussed below. 

Claim 12 And Its Dependent Claims Are Allowable Over The Cited Art 

Applicants respectfully traverse the obviousness rejection of claim 12 and its 
dependent claims. For at least the reasons given in previous submissions, Applicants 
respectfully submit that Thurston and Hind, either alone or in combination, do not teach, 
suggest, or otherwise render obvious these claims. 

Nevertheless, claim 12 is amended by the present response to clarify certain 
aspects of patentable distinctiveness over the asserted art. Namely, claim 12 is 
amended to recite a method for updating firmware in an electronic device of a system, 
the method comprising, inter alia, "populating the updating information in an update 
store that acts as a repository of update packages whose lifecycle may be managed; 
and managing the lifecycle of the updating information by changing status 
information for the lifecycle of the updating information, and enabling and disabling 
distribution of the updating information according to the status information for the 
lifecycle of the updating information." Additional support for this amendment may be 
found in the specification at, for example, paragraph [0053] ("Lifecycle management of 
an update package may comprise actions such as, for example, creating, deleting, and 
editing of update packages. Lifecycle management of update packages may also 
comprise changing status information such as, for example, information specifying who 
gets an update package, or when to start dispensing an update package.") 

Applicants respectfully submit that the cited art, either alone or in combination, 
does not teach, suggest, or otherwise render obvious at least changing status 
information for the lifecycle of the updating information, and enabling and disabling 
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distribution of the updating information according to the status information (which 
can be changed as part of managing the lifecycle) for the lifecycle of the updating 
information. For example, in maintaining its assertion that Thurston discloses 
"managing the lifecycle of the updating information by enabling and disabling 
distribution of the updating information according to a state in the lifecycle of the 
updating information, the Office Action states as follows: 

Examiner respectfully disagrees. The limitation as 
recited is interpreted to imply that managing the lifecycle of 
the updating information according to a state in the lifecycle 
of the updating information. Thurston discloses in Figure 7 
that distribution of update packages is enabled or disabled 
based on the status of the verification of system wide 
constraints which are based on the state of the updating 
information 702. 

(Office Action at p. 8.) As an initial matter, Applicant respectfully traverses this 
assertion for reasons detailed in previous submissions. The Office Action provides no 
explanation or support for how or why "system wide constraints" could or would be 
based on the state of the updating information. In any event, such an asserted "status 
of the verification of system wide constraints..." cannot teach the presently claimed 
subject matter. First, the presently claimed subject matter recites "changing status 
information for the lifecycle of the updating information." Such "verification of system 
wide constraints" for any given purported update information would not change. Either 
they are verified or not. The purported "verification" would not be changed, and as 
such, cannot teach changing status information for the lifecycle of the updating 
information. 

This is confirmed by an examination of the cited portions of Thurston relied upon 
as purportedly disclosing "managing the lifecycle of the updating information by 
enabling and disabling distribution of the updating information according to a state in the 
lifecycle of the updating information." The Office Action cites Figure 7 and paragraphs 
[0009], [0052], and [0053] as disclosing "managing the lifecycle of the updating 
information by enabling and disabling distribution of the updating information according 
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to a state in the lifecycle of the updating information." (See Office Action at p. 4.) 
Applicants first address [0009]. That paragraph reads as follows: 

[0009] In certain further implementations, the metadata 
further comprises a header, wherein the header includes 
characteristics of a firmware update package that includes 
the firmware image. The metadata also comprises of 
dynamic constraints, wherein the firmware update 
application determines whether the dynamic constraints are 
satisfied before installing the firmware image on the 
hardware device. In still further implementations, the header 
further comprises a version number of the header, wherein 
the version number is read by the firmware update 
application to identify a version of the header. The header 
also comprises a name of a device dependent plug-in 
module, wherein the named device dependent plug-in 
module is invoked by the firmware update application to 
interpret the dynamic constraints to determine whether the 
dynamic constraints are satisfied. 



Applicants respectfully submit such a teaching of "metadata" that comprises a 
"header" does not teach the presently claimed subject matter. For example, such a 
teaching is silent with respect to status information for the lifecycle of the updating 
information that can be changed, let alone managing the lifecycle of the updating 
information by changing status information for the lifecycle of the updating 
information, further still let alone managing the lifecycle of the updating information as 
fully set forth by claim 12, for example, including enabling and disabling distribution of 
the updating information according to the status information for the lifecycle of the 
updating information. 

The Office Action also cites paragraphs [0052] and [0053] as disclosing 
"managing the lifecycle of the updating information by enabling and disabling 
distribution of the updating information according to a state in the lifecycle of the 
updating information." (See Office Action at p. 4; see also id. at p. 6, asserting the 
same paragraphs disclose "wherein the lifecycle management system causes a change 
in the lifecycle state of updating information stored in a network that communicated the 
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updating information to the one or more electronic devices.") Those paragraphs read as 
follows: 

[0052] Control proceeds to block 704, where the 
device independent firmware update utility 302 requests the 
device dependent plug-in module 306 to confirm that system 
wide constraints are being satisfied before proceeding with 
the firmware installation. The system wide constraints may 
be distributed within the firmware update application 200 or 
the firmware package 108a, and may include constraints 
such as the version of the operating system, the amount of 
available storage, etc., that may need to be satisfied before 
installing the binary firmware image 404. The device 
dependent plug-in module 306 receives (at block 706) the 
request to verify the system wide constraints. The device 
dependent plug-in module 306 verifies (at block 708) the 
system wide constraints. If the system wide constraints are 
satisfied then the status is said to be "verified." In contrast, if 
the system wide constraints are not satisfied then the status 
is said to be "not verified." The device dependent plug-in 
module 306 sends (at block 710) the status on the 
verification of the system wide constraints to the device 
independent firmware update utility 302. 
[0053] At block 712, the device independent firmware 
update utility 302 receives the status on the verification of 
the system wide constraints from the device dependent 
plugin module 306. If the system wide constraints are "not 
verified" (at block 712), then control proceeds to block 714 
where the device independent firmware update utility 302 
performs cleanup operations and exits. Cleanup operations 
may include closing files that are open, disposing of pointer 
data structures, closing network connections, etc. If at block 
712, the device independent firmware update utility 302 
receives a "verified" status for the system wide constraints, 
then control proceeds to block 716 where the device 
independent firmware update utility 302 passes the device 
dependent plug-in module 306 the list of properties package 
402 containing the dynamic constraints, and requests the 
device dependent plug-in module 306 to discover matching 
hardware devices 31 0, 31 1 for firmware update. 

Again, a mere discussion of verification of system-wide constraints of a 
firmware image being installed does not disclose managing the lifecycle of the updating 
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information. As discussed in previous submissions, this is even more so for the 
"system-wide constraints" identified by Thurston as "such as the version of the operating 
system, the amount of available storage, etc., that may need to be satisfied before 
installing the binary firmware image 404," none of which are related to the lifecycle of 
updating information. In any event even if these portions of Thurston are somehow 
assumed, arguendo, as teaching "managing the lifecycle of the updating information by 
enabling and disabling distribution of the updating information according to a state in the 
lifecycle of the updating information" (which, as discussed previously, Applicants do not 
concede), Thurston's teaching is still silent with respect to status information for the 
lifecycle of the updating information that can be changed, let alone managing the 
lifecycle of the updating information by changing status information for the lifecycle of 
the updating information, further still let alone managing the lifecycle of the updating 
information as fully set forth by claim 12. For example, the cited portion of Thurston 
gives no indication for how or why such constraints that are "distributed within the 
firmware update application 200 or the firmware package 108a" could or would be 
changed for the same purported updating information. Similarly, Applicants respectfully 
submit there is no indication in Thurston of how or why "the version of the operating 
system" or "the amount of available storage" would change at all, let alone change with 
respect to the lifecycle of update information, further still somehow teach, suggest, or 
otherwise render obvious "managing the lifecycle of the updating information by 
changing status information for the lifecycle of the updating information, and enabling 
and disabling distribution..." as claimed. 

Applicants further respectfully submit the additional cited art does not remedy the 
above discussed shortcomings in the disclosure of Thurston. For the reasons 
discussed above, as well as in previous submissions, Applicants respectfully submit that 
the cited art, either alone or in combination, does not teach, suggest, or otherwise 
render obvious claim 12 or any claim dependent therefrom, and that those claims are 
allowable. 

Applicants further submit that claims dependent from claim 12 are further 
allowable over the cited art for additional reasons. For example, in responding to 
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Applicants' previously pointing out that the prior Office Action failed to support or explain 
its assertion that Thurston disclosed claim 15's requirement of "retrieving the requested 
updating information from the update store," the Office Action states as follows: 

Examiner respectfully disagrees. Figure 7 was cited 
to read on claim 15 as detailed above. Components not 
clear to applicant as reading on the features of claim 15 are 
mapped above in the rejection of claim 15. In particular, 
Thurston discloses extracting update information in 
Paragraph [0044] which reads on the retrieval of requested 
updating information. 

(Office Action at p. 8.) Applicants respectfully submit such asserted "retrieval of 
requested updating information" does not teach retrieving the requested updating 
information from the update store as expressly required by claim 15. Paragraph [0044] 
of Thurston reads as follows: 

[0044] The device independent firmware update utility 302 
extracts the list of properties package 402 from the firmware 
update package 108a and forwards the firmware update 
package 108a to the device dependent plug-in module 306. 
In alternative implementations, the device independent 
firmware update utility 302 may extract the <name, value> 
pairs from the list of properties package 402 and forward the 
name value pairs to the device dependent plug-in module 
306. The device dependent plug-in module 306 uses the 
<name, value> pairs to apply the dynamic constraints for the 
firmware update encapsulated into the <name, value> pairs. 

Such a teaching is quite different from the retrieval of requested updating 
information of claim 15. For example, this portion of Thurston merely discusses the 
extraction of a list of properties package and name, value pairs - such an extraction is 
different from retrieval as claimed, particularly retrieval from an update store. Further, 
Claim 15 depends from claim 12, so the update store from which the claimed requested 
updating information is retrieved is an update store that "acts as a repository of update 
packages whose lifecycle may be managed." The extraction relied upon, at most, 
comes from an update package itself, and does not teach retrieval of anything, let alone 
retrieval of, for example, an update package in the first place from an update store. 
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Claim 16 And Its Dependent Claims Are Allowable Over The Cited Art 

Applicants additionally respectfully traverse the rejections of claim 16 and its 
dependent claims. In rejecting claim 16, the Office Action cites to and relies on the 
same portions of Thurston as the Office Action cites to and relies on to reject claim 12. 
(See Office Action at p. 3-4.) Claim 16 is also amended generally similarly by the 
present response. Thus, for at least similar reasons to those previously discussed in 
connection with claim 12, as well as in previous submissions, Applicants respectfully 
submit that Thurston and Hind, either alone or in combination, do not teach, suggest or 
otherwise render obvious claim 16 or any of its dependent claims, and that those claims 
are allowable. 

Applicants further respectfully submit that claims that depend from claim 16 are 
further allowable for additional reasons. For example, with respect to claims 28 and 29, 
the Office Action relies upon Figs. 1, 4, 8 and paragraphs [0026]-[0027], and [0042] of 
Thurston. Applicants have reviewed Figs. 1, 4, and 8, and are unable to locate a 
database in those figures, let alone "updating status information for the particular 
version of updating information in a database of lifecycle information for update 
information" as claimed by claim 28, or "updating status information in a database of 
lifecycle information for the one or more electronic devices" as claimed by claim 29. The 
next cited portion, [0026]-[0027], reads as follows: 

[0026] The host 100 and the server 108 may be any 
computational device known in the art, such as a personal 
computer, a workstation, a server, a mainframe, a handheld 
computer, a palm top computer, a telephony device, etc. 
The networks 106, 110 may be any network known in the 
art, such as the Internet, an intranet, a local area network a 
wireless network, etc. The host 100 may alternatively be 
connected to the server 108 and the hardware device 104 
without a network, such as through direct lines, common bus 
systems, etc., in a manner known in the art. Also each 
network 106, 110 may be part of one or more larger 
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networks or may be an independent network or may be 
comprised of multiple interconnected networks. 

[0027] The hardware devices 102 and 104 may contain 
firmware 102a and 104a respectively. The server 108 may 
contain a firmware update package 108a, where the host 
100 may download the firmware update package 108a over 
the network 110 and use data contained within the firmware 
update package 108a to update the firmware 102a, 104a on 
hardware devices 102, 104. If a hardware device 102, 104 
has provisions for including firmware but has not installed 
firmware, then the host 100 may download the firmware 
update package 108a over the network 110 and install the 
firmware on the hardware devices 102, 104. 

Applicants respectfully submit, as an initial matter, that these paragraphs of 
Thurston make no express mention of any "database." In any event, even if, arguendo, 
these portions somehow disclose the mere use of databases, such a teaching would 
still fall far short of teaching, suggesting, or otherwise rendering obvious, for example, a 
database of lifecycle information, let alone updating status information in a database of 
lifecycle information for update information, let alone the updating of status information 
as fully set forth in either claim 28 or 29. Moving on to the next cited portion of 
Thurston, [0042] reads as follows: 

[0042] The list of properties package 402 contains 
properties, where each property is a dynamic constraint that 
may need to be satisfied before the firmware update 
application 200 installs the binary firmware image 404 on the 
hardware device 310, 311. The device dependent plug-in 
module 306 processes the dynamic constraints in addition to 
static constraints included in the device dependent plug-in 
module 306. For example, a dynamic constraint may 
indicate the version of the firmware upgrade in the firmware 
update package 108a. Since every new firmware update 
package 108a may have a different version, the version of 
the firmware upgrade can only be part of a dynamic 
constraint as the information cannot be known a priori to the 
device dependent plug-in module 306. 

Such a "list of properties package" or "constraints" cannot be stretched so far to 
teach a database, let alone a database of lifecycle information, or updating status 
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information in a database of lifecycle information for update information. As such, 
Applicants respectfully submit that this portion of Thurston does not remedy the 
shortcomings in the other cited portions of Thurston, and that claims 28 and 29 are 
additionally allowable. 

Conclusion 

In general, the Office Action makes various statements regarding claims 12-23 
and 26-34, and the cited references, that are now moot in light of the above. Thus, 
Applicants will not address such statements at the present time. However, Applicants 
expressly reserve the right to challenge such statements in the future should the need 
arise (e.g., if such statements should become relevant by appearing in a rejection of any 
current or future claim). 

Applicants believe that all of claims 12-23 and 26-34 are in condition for 
allowance. Should the Examiner disagree or have any questions regarding this 
submission, Applicants invite the Examiner to contact the undersigned at (312) 775- 
8000 for an interview. 

A Notice of Allowability is courteously solicited. 

Respectfully submitted, 



Date: August 4, 2009 /Kevin E. Borq/ 

Kevin E. Borg 
Reg. No. 51,486 

Hewlett-Packard Company 
Intellectual Property Administration 
Legal Department, M/S 35 
P.O. Box 272400 
Fort Collins, CO 80527-2400 
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